Docker 三本柱 a.k.a Docker 三劍客

• Docker Machine
• Docker Compose
• Docker Swarm

圖片來源

為什麼要先提這個？因為當我們微服務中的每個 components 都用 docker 包起來了，我們總是要把這些 docker 跑起來，個別的 docker ，我們可以使用 docker run 的指令，或是把 docker run 所需要的參數寫成 script ，部署時按照 script 跑起來。如果我們有很多 docker 要跑的時候，我們就需要編排 (Orchestration) ，意即控制這群 docker 的啟閉、環境變數設置、 mount point …等等。docker compose 可以處理在一台機器上的 docker 編排，而 docker swarm 可以同時處理多台機器上的 docker 編排。以前我們團隊會用 docker compose 來做基本的 dev 環境上的 docker 編排，甚至進行 dev branch 出 build 之後，要跑 BVT(Build Verification Test) 時的 docker 編排。剛開始還蠻好用的，一個 Yaml 檔可以控制幾十個 docker 的啟閉，但漸漸的，我們發現問題。

當涉及到複雜的相依性時，像是 API Gateway 的微服務 docker 一定要 DB 的 docker 已經 alive ，否則啟動時會報錯；或是複雜的 initialization ，例如 BVT 中，DB 的 docker 要 apply 大量的 SQL schema 並作檢查；當環境設置有上述這些行為時， docker compose 的表達能力往往就顯得力不從心，詳見 HOW I SWITCHED FROM DOCKER-COMPOSE TO PURE ANSIBLE的討論。

至於 docker swarm 與 kubernetes 的比較，我必須承認我沒有用過 docker swarm ，而且我也懷疑現在還有人把 docker swarm 用在 production 環境嗎？？Anyone using Swarm in production in 2019? How does it fair against k8s?

圖片來源

在我們團隊裡，新的 docker 三本柱應該是

• Docker 它本人
• Ansible with Docker module (簡單的 docker 編排)
• Kubernetes (production-ready 的 docker 編排)

我們會用 ansible 的 docker module 來做簡單的 docker orchestration、來進行 BVT 、甚至手動出 build 、 init db 、部署 docker 至 kubernetes ，事實上，我們用 ansible 控制一切。

結果今天還是沒寫到 code ，明天，明天就來寫 Yaml 了。

更：

有人問說能不能用 docker 來 host db ，像是 MySQL 之類的，這件事在前面的文章有提到，簡單的答案是：

在 Production 環境不要這麼做…

以 Cloud Native 的角度來看，我們可以在部署到 production 的時候，與平台提供的 RMDB 介接；而在開發階段使用 docker 來 host db 倒是沒什麼問題，主要的差別在 HA、Disaster Recovery、Sharding…等等，端看資料有多重要